It is a well-known problem that, in present network management systems, a network operator cannot see at a glance the whole picture of a communication network to be managed especially while the network operator monitors or tries to introduce any changes in the network. Such difficulty, of course, hampers both any reconfiguring of the network, and any attempts to change traffic flows in the network. Since any changes cannot be adequately analyzed in advance at the upper level of network management it become traffic-affecting.
One of the reasons for such problem is that heterogeneous networks to be managed have different protocol layers. In addition heterogeneous networks are built from layers of different pieces of equipment which are usually produced by different vendors. Different equipment samples have multiple, equipment-specific features and usually demonstrate significant technological gaps between them. Every management application is usually utilized for specific equipment capabilities, and is often technological-layer-oriented (i.e., is characteristic and suitable for its own technological layer). Usually, every management application has its own unique information base, screens and GUIs (Graphical User Interfaces) which are unavailable to other management applications/layers. This means that their information bases and screens cannot be seen and/or used from other layers.
For example, if a user wishes to modify a multipoint-to-multipoint Ethernet service with multiple endpoints which are distributed over different pieces of equipment, there might be a situation when the service will be created successfully at part of the endpoints, while at other endpoints it will fail. The failure may be caused by capabilities and features which may be supported/fulfilled by one type of equipment and not supported/fulfilled by other types of equipment. Such a situation is very undesirable for the end user since the service will appear to be only partially functional. Today there is no suitable pro-active approach which would allow the users to prevent such situation in a complex network comprising heterogeneous equipment. In other words, a modern network management system (NMS) is unable “to see” the whole picture of the network, with its complete set of its capabilities and features.
For example, a conventional system (FIG. 1) for managing a communication network comprises a central management unit (usually called the NMS) at a high management layer. The NMS is in bidirectional communications with a numerous of Element Management Systems (EMS) of a lower management layer EMS-1 . . . EMS-N. In turn, each of the EMSs communicates with a number of Network Elements (NE) that forms another, lower (basic) layer in the management system.
Each management layer of the system (NMS, EMS, NEs) has its own control and management applications, which can be defined as a sum or composition of properties and that are being intrinsic and/or performable at this specific layer. Usually, higher management layers of the system have their own software/hardware and GUI. Network elements are usually provided with main cards which serve as controllers of line cards of the network elements.
In the conventional system shown in FIG. 1, the operator interacts with the NMS and may get information about (and/or affect) only such functions which are performed at the level of NMS. For example, functioning of EMS-specific policers can be viewed/studied/affected only at the level of EMS. The term policers refer to software/hardware means for sorting packets at the input and/or output of a communication block, depending on throughput or capacity of the block. Most of the time, at the layer of NMS (for example, in a GUI of the NMS) EMS-specific information is unavailable.
Another example of a problem with the prior art, is that Services Definition and a current specific Quality of Service (QoS) model for traffic can usually be seen/managed only at the layer of EMS (e.g., at its GUI). This information is unavailable at the NMS.
Yet another example is that communication from/to Customer Virtual Local Access Network (CVLAN), and its dynamic association with one or another ports of specific equipment, can be observed and affected only at the layer of the EMS. Again this information is unavailable at the NMS.
Today, in order “to see” the whole picture of the network, the operator working at the level of NMS has to manually collect “a puzzle” of information from different management applications. This is a very difficult, cumbersome, time-consuming and error-prone process, especially nowadays when communication networks grow and their complexity increases.
On the other hand, full transfer of data from all EMSs to the NMS is also not practicable. First of all, it would cause excessive development efforts at the stage of designing NMS. Secondly, it would hamper the NMS operation, would make the working of EMSs cumbersome and would introduce a problem of synchronizing between EMSs and NMS.
An additional problem existing today is that the operator has no comprehensive tools to analyze the network and perform “if-then” (AKA “what-if”) simulations for various scenarios of hardware and/or traffic reconfigurations in the network. An “if-then” simulation for a scenario may be understood as a succession of events which may take place between two or more communicating points, when changes in topology and/or traffic are introduced between them. Quite often, end points of services, trails in Synchronous Digital Hierarchy (SDH), tunnels in Multiprotocol Label Switching (MPLS) are situated at different pieces of equipment which may be located at different levels/layers of the network
Presently, network simulations are performed by various versions of existing planning tools (which usually are placed at the layer of NMS). The presently known planning tools are intended for calculations and simulations of scenarios based on NMS input only, and for giving optimization recommendations. Such planning tools are isolated, self-contained applications. When the planning tools run software simulations, they do it internally, without any simulation interface to other management applications. Thus, the resulting solution found by such a planning tool may suffer from: low accuracy, and poor feasibility. In addition other problems may arise from the very limited information which is available to the specific planning tool with respect to other, lower management layers of the system.
Some prior art solutions suggest interaction between NMS and EMS layers of a communication system. One idea of carrying a simulation by a central control entity in a network before performing actual changes in that network is described in Applicant's U.S. Pat. No. 7,751,707. This solution proposes a technique for controlling an optical network comprised of network elements (NEs) with the aid of a network controller (NC) that is in communication with the network elements. The technique includes the network controller NC collecting information on the NEs there-from. Whenever a change in the network is requested, the NC simulates operation of the network with the requested change based on the collected information. The NC makes a decision on acceptability of the requested change, and may then cause implementation of the requested change in the network.
However, the above patent refers only to the optical technological layer, and only to a very limited set of changes which could be simulated For example the substitution of one entity (e.g. a network element or optical channel) to another is made. In the solution disclosed in U.S. Pat. No. 7,751,707, the simulation is held only in the Network Controller (NC), is only based on performance monitoring of network elements (NEs), and is not supposed to be held at other layers of the management hierarchy of the system.